This invention relates to the field of object-oriented programming. Specifically, it relates to a method of providing stand-in objects in an object-oriented programming environment.
Object-oriented programming is a method of creating computer programs by combining certain fundamental building blocks, and creating relationships among and between the building blocks. The building blocks in object-oriented programming systems are called xe2x80x9cobjects.xe2x80x9d An object is a programming unit that groups together a data structure (instance variables) and the operations (methods) that can use or affect that data. Thus, an object consists of data and one or more operations or procedures that can be performed on that data. The joining of data and operations into a unitary building block is called xe2x80x9cencapsulation.xe2x80x9d In object-oriented programming, operations that can be performed on the data are referred to as xe2x80x9cmethods.xe2x80x9d An object can be instructed to perform one of its methods when it receives a xe2x80x9cmessage.xe2x80x9d A message is a command or instruction to the object to execute a certain method. It consists of a method selection (name) and arguments that are sent to an object. A message tells the receiving object what to do.
One advantage of object-oriented programming is the way in which methods are invoked. When a message is sent to an object, it is not necessary for the message to instruct the object how to perform a certain method. It is only necessary to request that the object execute the method. This greatly simplifies program development.
Object-oriented programming languages are generally based on one of two schemes for representing general concepts and sharing knowledge. One scheme is known as the xe2x80x9cclassxe2x80x9d scheme. The other scheme is known as the xe2x80x9cprototypexe2x80x9d scheme. Both the class-based and prototype-based object-oriented programming schemes are generally described in Lieberman, xe2x80x9cUsing Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems,xe2x80x9d OOPSLA 86 Proceedings, September 1986, pp. 214-223.
An object that describes behavior is called a xe2x80x9cclass.xe2x80x9d Objects that acquire a behavior and that have states are called xe2x80x9cinstances.xe2x80x9d Thus, in the Objective C language, which is the computer language in which the preferred embodiment of the present invention may be implemented, a class is a particular type of object. In Objective C, any object that is not a class object is said to be an instance of its class. The classes form a xe2x80x9chierarchy.xe2x80x9d Each subdass in the hierarchy may add to or modify the behavior specified by its parent class and may also add additional states.
An object in Objective C may couple its data with the methods for operating on that data. However, when the data for an object is part of a relational database, the relationships among the stored data may also be retrieved, or xe2x80x9cfetched.xe2x80x9d For example, in an relational database where both Employee and Department information is stored, the Employee and Department information may be related (e.g., have a related column or columns). In such a case, once Employee data is retrieved to instantiate an Employee object, a corresponding Department object is also created and instantiated with data from the database that is related to the data from the Employee object. This process of instantiating a Department object with the data related to the instantiated Employee object is referred to as resolving the relationship between the Employee and Department objects.
If a fetched object has many relationships that are to be resolved when the object is fetched, system resources (e.g., processing time and memory) are consumed during the fetch operation to resolve the relationships. For example, an object is fetched that has relationships with other objects in the database and these other objects have relationships with still other objects in the database, a fetch operation is performed for each related object. For example, an Employee object may have relationships with objects such as Department, Employee ID, Salary, Start Date, Vacation Days, Sick Days, Health Benefits and Office. Fetching of the Employee object causes a fetch of all of these objects, as well as the data to fill these objects. Also, any objects related to these objects are also retrieved, causing unnecessary interaction with the database server, and significantly increasing processing time and memory requirements. When all of an object""s relationships are resolved regardless of whether a related object is needed, the processing time and memory requirements expended to resolve the relationships is wasted.
One prior art solution is to create an intermediate object called a xe2x80x9chandle.xe2x80x9d The handle acts as a xe2x80x9cgo-betweenxe2x80x9d and is used to reference objects related to a fetched object. For example, after the Employee object is fetched, the handle for the related Department object is created instead of the actual Department object. The handle may take any of various forms, such as a pointer to a pointer, a function call, a name look-up in a dictionary, or a method on some object. When code in the Employee object wishes to access the Department object, it must ask the handle for the information. The first time the Department object is accessed, the Department object is instantiated and stored in memory.
One disadvantage of this prior art method is that the program must always direct messages and inquiries to the Department object through the Department handle. The Employee object does not have direct access to the Department object or the Department data. Thus, an extra level of interaction and complexity to the code is created. Since not all objects get handles, different code must be written to interact with objects that have handles (e.g., the Department object) than to interact with regular objects without handles. Further, objects with handles look and behave differently than all other objects in the programming environment. Existing function libraries or other pieces of code written to manipulate regular objects will not work with handles because they expect to interact with the objects directly. Consequently, duplicate algorithms must then be written to interact with both handles and regular objects.
Another prior art method for dealing with this problem involves using the virtual memory system of the computer. In this scheme, when a pointer to a particular object is referenced, the virtual memory page faulting mechanism determines which page of memory contains the referenced object, and then retrieves the entire page. For example, when the Employee object wishes to access the Department object, a page fault is invoked, and the page of memory that contains the Department object is retrieved.
One disadvantage of this prior art scheme is that it is dependent on the virtual memory and API constraints of the virtual memory system of the computer system. Another disadvantage of this scheme is that more information is retrieved than is necessary, since an entire page of memory is retrieved for a reference to a single object. That is, for example, every object whose virtual address is contained in the page retrieved must be retrieved regardless of whether the object is actually needed. Further, a virtual memory system must be modified to access data from a conventional database system. For example, there must be some means for associated a virtual address of a referenced object and the data that must be fetched from the database to instantiate the object. When a page fault occurs, for example, the rowid of each row containing data for the objects whose virtual addresses are contained in the page must be determined and then used to fetch the data from the database to instantiate each object.
Thus, a flexible method for providing object fetching with reduced database server interaction and simplified code requirements is desired.
The present invention provides a method for delaying the instantiation of an object in an object-oriented environment. Instead of creating an actual object, a stand-in object is created. When an actual object is instantiated, a description is referenced to locate the data from a data source that is used to populate the actual object. The present invention can be used with any data source including a user interface, a file system, a database, and an object-oriented database, for example.
One application of the present invention provides a method for automatically resolving the relationships defined in an object oriented relational database model without the necessity of retrieving data from the database until it is needed. A xe2x80x9cfaultxe2x80x9d class is defined, as well as fault objects whose data haven""t yet been fetched from the database. An object that""s created for the destination of a relationship whenever an object that includes the relationship is fetched from the database. When an object is fetched that has relationships, fault objects are created to xe2x80x9cstand-inxe2x80x9d for the destination objects of those relationships. Fault objects transform themselves into the actual objectsxe2x80x94and fetch their dataxe2x80x94the first time they""re accessed.
This delayed resolution of relationships occurs in two stages: the creation of a placeholder object for the data to be fetched, and the fetching of that data only when it""s needed.
A fault object behaves in every way possible as an instance of its target class until it receives a message it can""t cover for. For example, if you send a class message to this fault object, it returns the Employee class. If you send the fault object a message requesting the value of an attribute, such as lastName, however, it uses the database channel that created it to retrieve its data from the database, overwrites its class identity, and invokes the target class s implementation of lastName.
By not fetching an object until the application actually needs it, unnecessary interaction with the database server is therefore prevented.